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ABSTRACT 


In order to meet the stringent time-critical requirements for real-time man-in-the-loop flight simulation, computer 
processing operations must be consistent in processing time and be completed in as short a time as possible. 
These operations include simulation mathematical model computation and data input/output to the simulators. In 
1986, in response to increased demands for flight simulation performance, NASA’s Langley Research Center 
(LaRC), working with the contractor, developed extensions to the Computer Automated Measurement and 
Control (CAMAC) technology which resulted in a factor of ten increase in the effective bandwidth and reduced 
latency of modules necessary for simulator communication. This technology extension is being used by more 
than 80 leading technological developers in the United States, Canada, and Europe. Included among the 
commercial applications are nuclear process control, power grid analysis, process monitoring, real-time 
simulation, and radar data acquisition. Personnel at LaRC are completing the development of the use of 
supercomputers for mathematical model computation to support real-time flight simulation. This includes the 
development of a real-time operating system and development of specialized software and hardware for the 
simulator network. This paper describes the data acquisition technology and the development of supercomputing 
for flight simulation. 


INTRODUCTION 

NASA’s Langley Research Center (LaRC) has used real-time flight simulation to support aerodynamic, space, 
and hardware research for over forty years. In the mid-1960s LaRC pioneered the first practical, real-time, 
digital, flight simulation system with Control Data Corporation (CDC) 6600 computers. In 1976, the 6600 
computers were replaced with CDC CYBER 175 computers. In 1987, the analog-based simulation input/output 
system was replaced with a high performance, fiber-optic-based, digital network. In 1990, action was begun to 
replace the simulation computers with supercomputers. 

The digital data distribution and signal conversion system, referred to as the Advanced Real-Time Simulation 
System (ARTSS) is a state-of-the-art, high-speed, fiber-optic-based, ring network system. This system, using the 
Computer Automated Measurement and Control (CAMAC) technology, replaced two twenty year old analog- 
based systems. The ARTSS is described in detail in references [1] through [6]. 

An unpublished survey of flight simulation users at LaRC conducted in 1987 projected that computing power 
requirements would increase by a factor of eight over the coming five-years (Figure 1). Although general 
growth was indicated, the pacing discipline was the design testing of high performance fighter aircraft. Factors 
influencing growth included: 1) active control of increased flexibility, 2) less static stability requiring more com- 
plex automatic attitude control and augmentation, 3) more complex avionics, 4) more sophisticated weapons 
systems, and 5) multiple aircraft interaction, the so called "n on m" problems. 

Having decided to continue using large-scale general-purpose digital computers, LaRC issued a Request for 
Proposals in May, 1989 and subsequently awarded a contract to Convex Computer Corporation in December of 
that year. As a result of this action, two Convex supercomputers are used to support flight simulation. The 
resulting computational facility provided by this contract is the Flight Simulation Computing System (FSCS). 
This system is described in references [8] through [11], 
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ADVANCED REAL-TIME SIMULATION SYSTEM 


Through design efforts by both LaRC design engineers and design engineers at KineticSystems Corporation, 
three components of the ARTSS were developed to meet LaRC requirements. These were the serial highway 
network, the network configuration switch, and the signal conversion equipment. A block diagram of the 

.ARTSS is presented in Figure 2. 

Serial Highway Network 

The LaRC ARTSS employs high-speed digital ring networks called CAMAC highways. At any given time, four 
totally independent simulations can be accommodated simultaneously. The equations of motion for an aircraft 
are solved on one of the mainframe computers and the simulation is normally assigned one highway. The 
purpose of the network is to transfer data between the central computers and simulation sites (control console, 
cockpit, display generator, etc.). The elements of a CAMAC highway are: the Block Transfer Serial Highway 
Driver (BTSHD); the fiber-optic U-port adaptor, the Block Transfer Serial Crate Controller (BTSCC); the List 
Sequencer Module (LSM); and the CAMAC crate. Three features of the networks were developed to meet the 
LaRC requirement. First, the mainframe computer interface to the BTSHD was developed. Second, the block 
transfer capability was developed to meet LaRC performance requirements. This capability resides in the 
BTSHD, BTSCC, and LSM. Third, the fiber optic capability was developed to satisfy our site distance problem. 
The simulator sites are from 350 to 6,000 feet from the computer center. 

Prior to the development of the block transfer capability, a CAMAC message was approximately 19 bytes long 
which included addressing, 24 bits of data, parity information, and response information. The addition of the 
block transfer capability allowed for the inclusion of many CAMAC data words in a single message. During 
block transfers, data reads or writes proceed synchronously at one 24-bit CAMAC data word per microsecond. 
This is several times faster than the normal single word message rate. Besides the CAMAC standard message, 
there are two modes of block transfer. In the first, the entire block of data goes to a single module within a 
crate. It is implemented by the BTSCC repeating the module-select and function bits on the crate dataway for 
each CAMAC word. In the second block transfer mode, the block, either on read or write, is divided among 
several modules within a crate. This mode employs the LSM module which is loaded by the mainframe 
computer at set-up time with up to four lists of module-select and function bits. When this type of block transfer 
is in progress, the BTSCC acquires module number, function, and subaddress for each sequential CAMAC word 
in the block from the indicated list in the LSM. 

To support Convex supercomputers, a new generation serial highway driver was developed. This driver provides 
direct connection to VMEbus and allows data to be streamed onto the network. Previous equipment transmitted 
24 bits out of the 32 available on the host computer interface; however, the new hardware transmits the full 32 
bits from the host computer. Packing/unpacking operations are no longer required to provide the 24 bits in 32 
which results in lower input/output latency and increased computer time available for model computation. 

Network Configuration Switch 

The purpose of the network configuration switch system is to provide complete connectability between the 
simulation applications on the mainframe computer and the various simulation sites. Upon request, any sensible 
combination of available sites can be combined into a local CAMAC ring network in support of a single 
simulation. This network configuration for a given simulation is done during the initialization phase, after a 
highway has been assigned by the scheduling software. The application job requests sites by resource request 
statements and if the sites are available, the switch will electrically and logically configure the network without 
disturbing other running simulations. The switch is built for a maximum of 12 highways and 44 sites. Each 
highway may be connected to a different host computer. During the transition period, four computers were 
routinely used simultaneously doing flight simulation. Two of these computers were CDC CYBER 175 
computers and two Convex supercomputers. In the final configuration, two Convex supercomputers with a total 
of six configuration switch ports are used. 
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Signal Conversion Equipment 


Three types of output converter modules and two types of input modules were designed and built to LaRC 
specifications. The converters are high quality and have been added to the vendor’s catalog. The digital-to- 
analog converters (DAC), analog-to-digital converters (ADC), and digital-to-synchro converters (DSC) are 16-bit 
devices with 14 bits of accuracy. The data transmitted uses 16 bits although only 14 are meaningful. This 
implementation allows LaRC to change converter precision without major changes in software or protocol. To 
decrease transmission time, data words are packed such that three converter words (16 bits each) are contained in 
two CAMAC words (24 bits each). The discrete input converters contain 48 bits per module and the discrete 
output modules contain 24 bits per module. 

Clocking System 

Flight simulation at LaRC is implemented as a sampled data system. The equations of motion are solved on a 
frame-by-frame basis using a fixed time interval. To provide the frame interval timing signals and a clocking 
system for synchronization of independent programs, LaRC designed and built the real-time clock system. This 
system is patented and is described in reference [7], The clock system is composed of a central unit and 
multiple CAMAC modules called Site Clock Interface Units (SCIUs) which are connected by means of a 
separate fiber optic star network. Two distinct time intervals are broadcast by the central unit on a single fiber. 
The first time interval has a constant 125-microsecond period. The tic count necessary for a real-time frame is 
set in the SCIU by initialization software. This count is decremented by one for each occurrence of the interval 
timer. When the count reaches zero, each SCIU issues a signal that indicates beginning of frame. The frame 
time is determined independently for each simulation but must be a multiple of 125 microseconds. The second 
clock signal, called the job sync tic, has a longer period called the clock common multiple which is set manually, 
typically in the 1 to 3 second range. This longer period is used for synchronization. Each frame time must 
divide evenly into the clock common multiple, ensuring that all simulations will be synchronized on the 
occurrence of the job sync tic. 

Figure 3 shows some of the wide variety of modules that can be accommodated in a CAMAC crate. The 
modules that are indicated as being developed to NASA specifications are available as standard catalog products 
from Kinetic Systems Corporation. The modules indicated as NASA developed were developed at NASA 
Langley Research Center. 

REQUIREMENTS FOR NEW SIMULATION COMPUTING SYSTEM 

The results of the 1987 survey of simulation users and program managers led to the definition of requirements 
for replacing existing computers. 

CPU Performance 


Real-time flight simulation at LaRC requires high scalar CPU performance to solve the equations of motion of 
the system being simulated. Using an existing simulation of an X-29 aircraft as a benchmark, the following 
CPU performance was specified: 

1. If a single CPU configuration is provided, the CPU must solve the benchmark in at most 165 seconds. 

2. If a multiple CPU configuration is provided, each CPU must solve the benchmark in at most 330 seconds. 

Due to secure processing requirements, a minimum of two and a maximum of four independent computers were 
required. The CYBER 175 computer solves the benchmark in 660 seconds. Thus, the capabilities of the 
resultant total system will provide at least eight times the CPU processing power of the coupled CYBER 175 
computers. 

Real-Time Input/Output 

The ARTSS CAMAC system has provided LaRC with a high performance real-time input/output system that has 
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extended the capabilities of the LaRC simulation system. Since ARTSS provides a high transfer rate with low 
latency, LaRC required provision of a compatible interface between the simulation computing system and the 
ARTSS CAMAC system. LaRC required that the new system include all software and hardware to connect to the 
ARTSS CAMAC real-time network. This connection was required to transfer block data over the network at a 
sustained rate of 24 million bits per second in the enhanced serial mode. 

Responsiveness 

One of the critical requirements for any real-time simulation system is system responsiveness. The FSCS system 
is required to respond to an external event, cause a short FORTRAN program to execute, and post an observable 
output response, in less than 150 microseconds. This elapsed time, called time-critical system response, is mea- 
sured at an external port on the computer. The external event occurs at a repetitive rate of 1000 events per 
second. In addition to the time-critical system response, CAMAC input/output response is required to be less 
than 200 microseconds. CAMAC input/output response is defined as the time between the action of an interrupt 
generated in a CAMAC crate, transfer of one CAMAC word of data, execution of the short FORTRAN program, 
and transfer of one CAMAC word of output. 

Frame Mate 


To support simulation applications needing higher frame rates, LaRC required the system to run simulations at 
1000 frames per second. At this frame rate, during any given frame, the system must deliver at least 600 micro- 
seconds of CPU time for the simulation model with 100 bytes of real-time input and 100 bytes of real-time out- 
put. The sum of system overhead and real-time input/output must be less than 400 microseconds. 

Real-Time Data Recording and Retrieval 

To support real-time data recording and retrieval during synchronous flight simulation, LaRC required the 
capability to record and/or retrieve information from two files for each simulation. The aggregate storage 
capacity was required to be a minimum of 180 megabytes. Sufficient data rate was required to permit a 
simulation to record or retrieve one 1000-byte record per real-time frame from each file simultaneously at a 
frame rate of 100 frames per second. 

Language and other factors 


At LaRC, almost all simulation programs are written in the FORTRAN language. Furthermore, simulations have 
been developed on CDC 6000 series computers and succeeding generations for over twenty years. With 
simulations written taking advantage of the CDC 60-bit architecture, LaRC required that the FSCS system 
support simulations written in the FORTRAN language with a minimum floating point mantissa precision of 14 
decimal digits and with a min im um exponent range of plus and minus 250 decimal. In addition, the C language 
is required to support a limited number of applications, and Pascal is required to support the CAMAC 
configuration database. 

An application development capability was required to operate simultaneously with simulations operating in real- 
time using all the real-time computing power specified. This application development capability has a minimum 
performance specification and required an advanced source language level debugger. 

NEW SIMULATION COMPUTING SYSTEM 

The computers that LaRC has put in place to fulfill the requirements are Convex Computer Corporation C3200 
and C3800 series computers. These computers are classified as supercomputers and support both 64- and 32-bit 
scalar, vector, and parallel processing. The first delivery consisted of a Convex C3230 (3 CPUs expandable to 
4) with two CAMAC interfaces. The system was delivered with two peripheral buses (PBUS): one PBUS that 
is used for input/output to standard peripherals such as tape, disk, and line printer and one PBUS that is used 
exclusively for real-time input/output to the ARTSS CAMAC network. Each VME Input/Output Processor 
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(VIOP) is a Motorola 68020 microcomputer that provides programmable input/output control. Each VIOP is con- 
nected to a standard 9U VMEbus and to the corresponding PBUS. The CAM AC interface consists of a 
KineticSystems Model 2140 Enhanced Serial Highway Driver for VMEbus. The second delivery consisted of 
one Convex C3850 (5 CPUs expandable to 8) computer configured similar to the C3230 with 3 PBUSs and two 
CAM AC interfaces. The computer contains 512 megabytes of main memory and sufficient disk and other 
peripherals to support flight simulation. The resulting computer configurations are shown in Figure 4. 

There are four critical aspects of a computing system to support real-time simulation. These are: CPU 
performance, memory capacity, time-critical system response, and deterministic system performance. 

The first computer installed (C3230) performs a simulation of an X-29 aircraft in 245 seconds per CPU which is 
2.7 times faster than the computers being replaced. With two CPUs available for real-time, this results in over 5 
times the CPU performance. The second computer (C3840) performs the X-29 in 1 17 seconds per CPU which is 
5.6 times faster than the computers being replaced. With four CPUs available for real-time, this results in over 
18 times the CPU performance. 

Memory capacity is more than adequate to meet the requirements. The expanded memory capacity, compared 
with the old system, has allowed LaRC researchers to greatly increase the complexity of the simulations. The 
increase in memory capacity, coupled with the increase in CPU performance, has led to much higher fidelity 
simulations. Memory capacity is high enough to permit its use for real-time data storage and retrieval. If the 
data requirements of the real-time simulations exceed the memory capacity, a disk spooler program will be 
developed. 

Time-critical system response is a measure of how fast the computing system can respond to real-time events 
from outside the computing system. Time-critical system response on both the computing systems has been 
measured at 31 microseconds, which exceeds the LaRC requirement. 

Deterministic system performance is a measure of how consistently on a frame-by-frame basis the computing 
system calculates the simulation model without any loss in synchronization with real-time. To use a computing 
system for real-time simulation, the system must be able to solve the model in a very nearly fixed amount of 
time, no matter what the demands on the system are for other computing. The C3850 performs simulation 
models with less than one percent variation in model computing speed. Modifications to the C3230 software are 
being done to improve its model computing behavior. 

Operating System 


Convex Computer Corporation offers two real-time operating systems. The operating system currently in use at 
LaRC requires one CPU for all non-real-time activity: editing, program compilation, and other UNIX activities. 
The other CPUs may be dedicated to real-time simulation. At the request of a real-time program, the program is 
locked down in memory to prevent page faults and the CPU or CPUS are dedicated exclusively to the real-time 
program. 

The second real-time operating system incorporates a specially developed real-time kernel that the entire 
operating system is built upon. With this version of the real-time operating system, the UNIX operating system 
portion will be pre-empted by real-time requests and the response to real-time interrupts will be deterministic and 
very short. This version supports, on a single CPU, all activities of a normal UNIX operating system and also 
simultaneously supports real-time applications. This operating system requires special hardware that is not 
available in LaRC computers. 


CONCLUSION 

NASA Langley Research Center is completing the development of a system to simulate in real-time increasingly 
complex and high performance modem aircraft. Utilizing centralized supercomputers coupled with a proven 
real-time network technology, scientists and engineers are performing advanced research using flight simulation. 
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Hardware and software developed and concepts used are applicable to a wide range of commercial applications 
that require time-critical computer processing including process control, power grid analysis, process monitoring, 
radar data acquisition, and real-time simulation of a wide variety of systems. 
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Flight Simulation Research Requirements 



Figure 1. 
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Langley Flight Simulation System 



Figure 2. 


136 















Typical CAMAC Crate Configuration 



ACC - auxiliary crate controller 
ADC - analog-to-digital converter * 

BTSCC - block transfer serial crate controller * 
DAC - digital-to-analog converter * 

Dl - discrete input converter * 

DO - discrete output converter * 

DSC - digital-to-synchro converter * 

LSM - list sequencer module * 

MIM - minicomputer interface module ** 

SCIU - site clock interface unit ** 

UPORT - fiber optic/electrical converter * 

* developed to NASA specifications 

** developed by NASA 


Figure 3. 
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Computing System Configuration 

Convex C3230 Computing System 



Convex C3850 Computing System 



Figure 4 
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